|
|
|
|
|
|
|
The code for the methods in Table 12.1 is on the CD-ROM. The interface class, IController, abstracts the common methods that many of the controllers implement. |
|
|
|
|
|
|
|
|
Using the Facade Design Pattern |
|
|
|
|
|
|
|
|
The Facade design pattern comes from the book Design Patterns by Gamma, et. al. This pattern provides a mechanism for better organizing the interfaces between one subsystem and another. |
|
|
|
|
|
|
|
|
Facades are just what the name implies. They are like faces between subsystems. To be exact, these faces are interfaces. As you create the Graphical User Interface Subsystem, you need to decouple it from the other subsystems with which it interacts. For the Graphical User Interface Subsystem, controller classes perform this role well. As you should remember, controller classes control the flow of events between forms and business/domain classes. Sometimes, the flow of events can originate from more than one form per controller. Such is the case with TransactionProcessor. Let's examine this controller in more detail with respect to its role as a complex facade. |
|
|
|
|
|
|
|
|
Learning How to Implement in Visual Basic |
|
|
|
|
|
|
|
|
Implementing the Facade design pattern is easy. There's a good chance you, or a developer you know, already use classes in Visual Basic in a facade manner. Essentially, wherever you have two interface classes representing two subsystems that intercommunicate, you can decouple these interface classes by inserting a facade between them. |
|
|
|
|
|
|
|
|
In the Bank example, the TransactionProcessor controller is a facade between both the frmCashDepositRecord and frmAccountDetail forms and their respective objects, CashDepositRecord and AccountDetail. |
|
|
|
|
|
|
|
|
Figure 12.3 shows the class model involving the TransactionProcessor and the Graphical User Interface and Business Rules Subsystems between which it serves as a facade. |
|
|
|
|
|